1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, systems, and products for user defined preferred DNS routing.
2. Description of Related Art
The Domain Name System (“DNS”) is a name service typically associated with the Internet. The DNS translates domain names in network addresses. The domain names are names of computer hosts providing network service such as web servers, email servers, and others. The network addresses are the network addresses of the network host computers. In the example of the Internet, the network addresses are often internet protocol (“IP”) addresses. Domain names are expressed in alphabetic text, easier for humans to work with than numeric network addresses. Networks, however, operate on numeric network addresses. Every time a user requests a resource by use of a domain name, therefore, a DNS service somewhere translates the domain name into a corresponding network address. The domain name “ibm.com,” for example, might translate into the IP network address 129.42.19.99. The DNS is actually a network in its own right, a network of DNS servers. If one DNS server is unable to translate a particular domain name, that server can obtain additional information from other DNS servers in the network.
The goal of domain names is to provide a mechanism for naming resources in such a way that the names are usable in different hosts, networks, protocol families, internets, and administrative organizations. From the user's point of view, domain names are useful as arguments to a function, called a resolver, which retrieves information associated with the domain name. Thus a user might ask for the host address or mail information associated with a particular domain name. To enable the user to request a particular type of information, an appropriate query type is passed to the resolver with the domain name. To the user, the domain tree is a single information space; the resolver is responsible for hiding the distribution of data among name servers from the user.
Resolvers are programs that extract information from name servers in response to client requests. Resolvers must be able to access at least one name server and use that name server's information to answer a query directly, or pursue the query using referrals to other name servers. A resolver will typically be a system routine that is directly accessible to user programs, so that no protocol usually is needed between the resolver and the user program. Both the name server and resolver are software processes executing on one or more computers. Essentially, the resolver submits a query to a name server about a domain name. The name server “resolves” the mapping of the domain name to a machine address and sends the machine address back to the resolver as the “answer” to the query.
In many network hosts, a resolver is part of the operating system. More particularly, in the case of TCP/IP, the resolver is often part of the TCP/IP client accessible from the application level through a C or C++ call through an Application Programming Interface (“API”) such as the sockets API. The Microsoft Windows™ Sockets API, for example, provides functions named gethostbyname( ) and WSAAsyncGetHostByName( ) that respectively work synchronously and asynchronously to obtain network addresses for network hosts given the hosts' domain names as inputs. Similarly, the Java method InetAddress.getByName(string host) is a static Java method that instantiates an object of class InetAddress representing the internet protocol address of a network host.
DNS includes a request/response data communications protocol with standard message types. Gethostbyname( ) and InetAddress.getByName( ) are examples of API calls to a TCP/IP client in an operating system such as Unix or Windows. Such a TCP/IP client typically bears one or more predesignated DNS server addresses, designations of a primary DNS server for a computer and possibly one or more secondary DNS servers. In response to a call to a resolver function such as gethostbyname( ) and InetAddress.getByName( ), a TCP/IP client sends a DNS request message containing the domain name in a standard format to a predesignated primary DNS server requesting a corresponding network address, and, upon receiving a response message, provides the network address in return to the calling program.
When a calling application receives the network address from the operating system, it can use the network address to access resources on the network host identified by the domain name associated with the network address. The network host can be any computer connected to the network. In the example where the calling application is a web browser executing on a user's computer, after the user types in a domain name and the browser (via the resolver process) receives the network address for the domain name, the next action is to transfer a request to the network host's address for a specific web page to be displayed on the user's web browser.
It is useful to distinguish domain names and URLs. URLs identify resources available through network hosts having domain names that form a portion of the URL. In the browser example, when a user requests access to a resource by entering a URL or selecting a URL by mouse-clicking a hyperlink, the browser extracts from the URL the domain name of the host on which the resource is located and submits the domain name to a resolver. The browser then uses the returned network address to establish a data communications connection to the host containing the resource and uses the entire URL to request the resource from the host.
As discussed above, conventional TCP/IP clients typically bear one or more predesignated DNS server addresses, designations of a primary DNS server for a computer and possibly one or more secondary DNS servers. These conventional TCP/IP clients have a number of drawbacks. Often the DNS server addresses must be predesignated by a system administrator or user having administrator privileges and therefore many users do not have sufficient privileges to predesignate DNS server addresses. Furthermore, such conventional TCP/IP clients often have the same predesignated DNS server addresses and therefore, all domain names are resolved through the same predesignated DNS server addresses. If a predesignated DNS server address is unavailable, a particular domain name may not be resolved. Even further, these conventional TCP/IP clients do not provide a mechanism to designate different DNS server address for different domain names. If a predesignated DNS server has no immediate capability of resolving a domain name, that server is faced with a laborious procedure of, for example, querying a top level DNS server to try to locate another DNS server that is in fact capable of resolving the domain name. There is ongoing need for improvement in users' ability to designate preferred DNS servers for particular domains.